feat: datum-ui v0.2 — monorepo scaffold, component library, tests, storybook, docs#13
feat: datum-ui v0.2 — monorepo scaffold, component library, tests, storybook, docs#13yahyafakhroji wants to merge 12 commits intomainfrom
Conversation
- Initialize v0.2 monorepo with turborepo, pnpm workspaces - Add @repo/config (eslint, tsconfig presets), @repo/shadcn primitives - Scaffold @datum-cloud/datum-ui with tsdown multi-entry build - Add DatumProvider with theme system and design tokens - Migrate all branded components from cloud-portal shadcn module - Extract form primitives (input, select, checkbox, switch, textarea, radio-group, autocomplete) to top-level component directories - Add compound Form library with stepper, validation, and Conform.js - Add data-table, task-queue, time-range-picker, and 20+ components - Set up Storybook with Rsbuild and Fumadocs documentation site - Add Vitest test infrastructure with component tests - Configure changesets for versioning
|
There are errors trying to run storybook in this branch I could not get it to load but it looks like it heads in a great direction. Do you have any reservations keeping this as a Draft for now? I think we can merge this before we merge the Button replacement in the staff portal if we are happy with this. Once we decide on this we can expand on the component adoption in the staff portal / begin adoption in the cloud portal. |
…mponents) Adds comprehensive test coverage for all datum-ui components including render, props, and interaction tests. Covers simple components (badge, button, input, etc.), complex composites (form system with validation, data-table with sorting/filtering), and utility components (toast, loader-overlay, empty-content). Also adds shared test utilities (renderWithProviders with DatumProvider + TooltipProvider) and jsdom polyfills (ResizeObserver, pointer capture, scrollIntoView) for Radix UI compatibility.
Adds lefthook to run ESLint (with auto-fix) and TypeScript type checking on staged files before each commit. Also adds a typecheck script to datum-ui and a typecheck task to turbo.json.
…nt/typecheck - Rewrite all storybook stories to use @datum-cloud/datum-ui exports - Add 30+ new stories (form, stepper, task-queue, sidebar, data-table, etc.) - Bundle empty-content images as data URLs via tsdown loader - Fix stepper story to use @stepperize/react v6 API (Stepper.Provider) - Fix ReactNode controls crashing storybook (icon, actions argTypes) - Remove redundant autodocs config from storybook main.ts - Expand form stories to 14 variants covering all Form sub-components - Add ESLint + typecheck scripts to storybook package - Configure storybook ESLint with story-specific rule overrides - Update lefthook to also check storybook (lint + typecheck) - Add react-day-picker and @tanstack/react-table as storybook dev deps
…alog - Configure fumadocs (v15) with datum-ui theme token mapping - Add ComponentPreview for live component rendering in MDX - Add getting started guides (overview, installation, theming, providers) - Add documentation pages for all 50+ components across 8 categories - Add hook documentation (useDebounce, useCopyToClipboard) - Handle client/server boundary with 'use client' wrapper layer
|
@kevwilliams Hi Kevin, sorry for the error experience. This PR is still a draft when you tested it, so I'm still developing it. However, you can try it again. I've completed this PR with all the components from the base cloud portal, Vitest, Storybook, and the docs site. |
- Add CI workflow with lint, typecheck, test, and build jobs on PRs - Restore release workflow with changesets for versioning - Restore publish workflow using datum-cloud/actions reusable workflow
e46a23a to
f3e403a
Compare
- Introduce functions to convert dates to UTC timestamps for start and end of day in specified timezones. - Update datepicker component to utilize new timezone utilities for accurate date filtering.
…stency - Refactor button variant styles in button.tsx to utilize new theme variables for primary, secondary, tertiary, and quaternary buttons. - Introduce new CSS variables for button colors in alpha.css, enhancing light and dark mode support. - Ensure consistent hover and active states across button types with updated color definitions.
- Update font-family definitions to use single quotes for consistency. - Simplify button color-mix definitions by removing unnecessary line breaks. - Ensure uniformity in button active states across primary, secondary, tertiary, and quaternary styles.
| "mode": "auto" | ||
| } | ||
| ], | ||
| "typescript.tsdk": "node_modules/typescript/lib", |
There was a problem hiding this comment.
can we keep this in please?
|
@yahyafakhroji I have a concern about data table component. Since staff portal relies heavily on tables, its layout will likely be different from cloud portal. Can we make data table more generic and flexible component instead of having a fixed layout? From what I see, the current implementation seems to be tightly based on the cloud portal’s layout. For example, it would be great if we could freely position components like the filter or search bar (e.g., on the right or left). Is it possible to allow each portal to arrange the layout as needed while still using the same shared data table component? |
|
Just to give you an idea, this is what I implemented in staff portal though I’m sure the approach can still be improved. The main concept is that we wrap the table with a provider. By doing that, we can freely place any related components anywhere in the layout, as long as they are inside the provider. This gives us flexibility to arrange the UI differently for each portal, while still using the same underlying data table logic. |
|
@gaghan430 That makes sense, perhaps we can spend some time on the data-table area in a separate issue. Because data-table are quite complex components, and considering our integration with client-side, server-side, search and filter |
|
yes, sounds good... we can create new ticket for that |
Summary
Complete restructure of the datum-ui package from a flat component library into a scalable monorepo-based design system with a two-layer architecture (shadcn primitives + datum components), full test suite, Storybook explorer, and Fumadocs documentation site.
What Changed
Architecture
src/components/with individual barrel filesTesting (new)
Storybook (new)
Documentation Site (new)
'use client'wrapper layerQuality
Old Setup vs New Setup
src/<component>/directoriessrc/components/<component>/with single top-level barrelForm.*API with validation, field arrays, multi-stepTest Plan
pnpm --filter datum-ui test— 204 tests passingpnpm --filter storybook build— builds successfullypnpm --filter docs build— 57 static pages generatedpnpm --filter datum-ui typecheck— no type errors